Problem

When the cloud batch request inside __get_prop_handler raises (timeout, network error, transient HTTP failure), the pending futures registered in self._get_prop_list stay unresolved forever. Because get_prop_async looks up _get_prop_list[key] at the top and return await prop_obj['fut'] if found, every subsequent call with the same (did, siid, piid) reuses the dead future — the integration never recovers from a single batch failure until Home Assistant is restarted.

Reproduction

1. Have any custom poller call get_prop_async periodically (e.g. an async_update override on a property entity, or homeassistant.update_entity triggered from an automation).
2. Wrap the call in asyncio.wait_for(..., timeout=N) shorter than __mihome_api_post_async's 30 s timeout — common when working around HA's 10 s "entity update is taking over 10 seconds" warning.
3. Make one batch hang past the caller's timeout (slow cloud response, proxy/DNS pollution, brief network blip).
4. The caller's wait_for cancels, but the underlying future created at line 800 stays pending. From that moment on, every poll for that key resolves the same dead future → entity values silently freeze with no error in the logs.

In the affected integration the only path back to a working state is a HA restart that clears _get_prop_list.

Fix

Wrap the await self.get_props_async(...) call in try/except and fall through with results = []. The existing fallback loop right below already iterates every key still in props_req, pops it from _get_prop_list, and calls set_result(None) — so reusing that path drains all stale futures and frees the cache slots. The next aggregation cycle starts fresh.

The change is contained to one block in miot/miot_cloud.py::__get_prop_handler. No public surface, return value, or call site changes. The broad-except + lazy _LOGGER.error formatting follow the existing convention used elsewhere in miot_lan.py / miot_network.py.

Verification

• pylint --rcfile=.pylintrc custom_components/xiaomi_home/miot/miot_cloud.py → 10.00/10
• Manually verified in production: before the fix, a transient cloud hang caused property entities to permanently stop updating until HA restart; after the fix the next 30 s aggregation cycle recovers cleanly.

Possibly related issues

These open issues describe the exact symptom this fix addresses ("data stops updating, reload/restart restores it"), though they likely have multiple root causes — this PR only covers the cloud-batch-failure → future-leak path:

• 设备状态不更新 #1334 — 设备状态不更新
• 花花草草植物检测仪状态不更新 #1698 — 花花草草植物检测仪状态不更新（cloud-poll path, directly hits get_prop_async）